home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 15276 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.5 KB

  1. Path: news.lpr.carel.fi!usenet
  2. From: Ari Lukumies <aril@cmt.lpr.mail.carel.fi>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: big endian, little endian
  5. Date: Thu, 18 Apr 1996 11:20:04 +0300
  6. Organization: Carelcomp Products
  7. Message-ID: <3175FB34.349@cmt.lpr.mail.carel.fi>
  8. References: <4ku9dm$t1t@news.ycc.yale.edu> <829609443snz@willen.demon.co.uk> <4l2ceg$ill@macondo.dmu.ac.uk>
  9. NNTP-Posting-Host: renoir.cclahti.carel.fi
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. Andrew Buckby wrote:
  16. > It the way inwhich number are stored in bytes. I may be wrong but I think that
  17. > Intel stores the highest bit on the right and the lowest on the left, 68000 and
  18. > most UNIX machines store it the other way with the highest bit on the left.
  19. > intel   64 32 16 8 4 2 1      others  1 2 4 8 16 32 64
  20.  
  21. Highest bit vs. lowest bit left or right? Geez, I thought we stored bytes... But, 
  22. maybe it will be like this (hex 82, ie. 10000010 in bits):
  23.  
  24. intel: 01000001        68k: 10000010
  25.  
  26. Well? Actually, I've encountered a machine where this _seems_ to be true: Tandem 
  27. NonStop series. The thing there, however, was the Tandem's way of numbering the 
  28. bits, not their order:
  29.  
  30. Bit numbers:
  31. intel:    76543210    Tandem: 01234567
  32. 0x82:    10000010        10000010
  33.  
  34. Whether they were stored little or big-endian here, didn't matter. What mattered was 
  35. what bit number you used (in source code) if you wanted to set, say, the bit that 
  36. would alter 0x82 to 0x86.
  37.  
  38. Later,
  39.  AriL
  40. -- 
  41. All my opinions are mine and mine alone.
  42.